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(57) Abstract: Extending network capabilities for a network with a policy-based network management (PBNM) architecture. The 
O method includes sending a first message from a policy enforcement point (PEP) to a policy decision point (PDP) in response to ah 
^ external action, and sending a Java object in a second message from the PDP to the PEP in response to receiving the first message. 
^ The Java object may be executed on the PEP to implement a policy. 
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EXTENSIBLE POLICY-BASED NETWORK MANAGEMENT ARCHITECTURE 

BACKGROUND 



1. FIELD 

The present invention relates generally to management of networks of 
compter systems and, more speo ffl ca„y, to policy-based network management 

2. DESCRIPTION 

and dTTT neh " 0rt< mana9emem " 9rOWin9 ™* 

and dfficult due ,„ part to me unrelenting expansion of today's enterprise 

~;- h New app,icauons such as -** ^ess 

nicest-based aprons, and multimedia require a network , ha, is capab, e 

of supporting trafr,c leve, mentoring, setf-reconfiguration, multipoint 

oommun^on. software distribution, securi*. and of ad^ng to change 

appl.cabon requirements through depbymen, of new services. Policy-based 

netwo* management (PBNM) is a recent approach to network management 

that attempts to provide a higher level interface to netwo* management than 

has been previously available. PBNM hides the low-level mechanisms of 

netwo* management behind a high level abstraction called pCicies. PCicies 

are human-readable, simple to express proposKions ma. dictate what actions 

and behav,ors are permitted on a computer netwo*. Using PBNM, a network 

adm,n,s.ra.or can express a set of policies governing the network For 

example one policy might be "allow members o, the engineering department to 

.serve 100 KbKs* of network bandwidth between the hours of 9:00 AM and 

5.00 PM. The underlying pbnm architecture handles the resolution of 
.ech nKa , issues such as fte assoc . at . on of ^ |nteme( ^ 

addresses to group membership, de.e*n and permission/refusal of bandwidth 
Rations, time o, day that a bandwidth request is to be active, and so on 
Th,s abstract of network management and the associated hiding of the 
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specific mechanisms used to implement policies allow for a richer, more 
powerful set of services to be managed and deployed on computer networks. 

Current PBNM architectures use a static, localized set of mechanisms for 
controlling the behavior of computer networks. One known PBNM protocol is 
the Common Open Policy Service (COPS) protocol. The COPS protocol is a 
"work in progress" or draft protocol of the Internet Engineering Task Force 
(IETF) dated August 16, 1999, which may be found on the Internet at 
http://www.ietf.org/intemet-drafts/draft-ietf-rap-cops-07.txt . The COPS protocol 
describes a client/server model for supporting policy control over Quality of 
Service (QoS) signaling protocols and provisioned QoS resource management. 
In the COPS protocol, clients, called policy enforcement points (PEPs), relay 
information about network resource requests to policy decision points (PDPs), 
which interpret policies so as to determine whether a request for network 
service should be honored or not. More generally, policies consist of sets of 
conditions that must be met before certain actions can be taken. 

For each new type of managed network resource, an extension must be 
defined for the COPS protocol (through the IETF procedures). In addition, 
changes must be made in the PEPs to allow outsourcing of decisions via the 
newly extended COPS protocol. The conditions and actions taken as a result of 
an evaluation by a PDP are fairly static as well. Typically, the actions consist of 
allowing or rejecting access to some resource (e.g., network bandwidth, 
multicast groups, etc.), along with a small set of predefined conditions such as 
group membership and time of day. In addition to these requirements, the 
conditions used in PEPs to trigger requests for policy evaluation, as well as 
actions taken by PEPs in response to such evaluation, tend to be strictly local in 
scope (that is, focused on a single network node). Thus, the policy evaluation 
conditions used in PEPs typically do not take into account the state of other 
devices in the network. 

While PBNM provides a powerful means of managing computer 
networks, its static definition of the mechanisms that can be manag d and the 
actions that can be decided on makes it slow to respond to the rapid evolution 
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of network services and capable* that is taking place. Furthermore, the local 
scope of PBNM conditions and actions tend to M the network-wide utility of 
PBNM to solving those problems which do not require access to the global state 
of the network. 



SUMMARY 



An embodiment of the present invention is a method of extending the 
capabilities of a network with a policy-based network management (PBNM) 
architecture. The method includes sending a first message from a policy 
enforcement point (PEP) to a po.icy decision point (PDP) in response to an 
external action, and sending a Java object in a second message from the PDP 
to the PEP in response to receiving the first message. 

Another embodiment of the present invention includes sending a first 
message from a policy enforcement point (PEP) to a policy decision point 
(PDP) requesting configuration of conditions, sending a Java object in a 
second message from the PDP to the PEP in response to receiving the first 
message, and executing the Java object on the PEP to configure conditions 
controlling the sending of messages from the PEP to the PDP. 
Other embodiments are described and claimed. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The features and advantages of the present invention will become 
apparent from the following detailed description of the present invention in 

which: 

Figure 1 is a diagram of a policy enforcement point interacting with a 
policy decision point for dynamic policy actions according to an embodiment of 
the present invention; 
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Figure 2 is a diagram illustrating dynamic policy conditions according to 
an embodiment of the present invention; 

Figure 3 is a diagram illustrating dynamic policy conditions taking into 
account network-wide state information according to an embodiment of the 
present invention; and 

Figure 4 is a diagram illustrating a sample processing system capable of 
being operated as a policy decision point according to an embodiment of the 
present invention. 



DETAILED DESCRIPTION 

As enterprise network and computing devices such as routers and 
servers have become more computationally powerful, new features have been 
added to these devices which leverage the available processing power to 
enable greater extensibility. In particular, the use of Java Virtual Machines 
(JVMs) has appeared in computer industry applications and academic research 
as a flexible, secure method of running programs to extend the functionality of 
devices that previously only supported a fixed set of features. 

An embodiment of the present invention extends the current policy- 
based network management (PBNM) architecture by utilizing the benefits 
afforded by the Java programming language and JVMs. An embodiment of the 
present invention allows network administrators and PBNM vendors to 
programmatically extend the set of conditions and actions that may be 
incorporated into policies in a PBNM system. In one embodiment, this 
extension may be accomplished using the Common Open Policy Service 
(COPS) protocol, although other embodiments may use other protocols. One 
embodiment of the present invention uses the COPS protocol to carry Java 
objects (e.g., self-contained programs) between policy decision points (PDPs) 
and policy enforcement points (PEPs). This usage of the COPS protocol to 
carry dynamic, executable programs rather than static configuration and 

4 



WO 01/19031 

dec,s,on .nformation is a powemj| ^ ^ ^ ^ ^ ■ ■ 

21 COmmUniCa ' eii ^ ' hiS arChi,eC,Ure " P"*—-* 
network aware ,p«o„, the obje c,s have „» abiljty , 0 ^ " 

ZTl W TI instance5 of such appfca,ions ( ""°*« " «*- — 

w,th,n the network,, hereby providing a greate r degree of in.e,PEP 
com m u n i ca ,ion then before, in general, by sending Java objects to PEPs the 
PEPs may use a richer se, of conditions for policy evaluate and implement a 
more powerful set of actons for manipulating (he state of the network 

Reference in the spedflcation to 'one embodiment- or -an embodiment" 
o the present invention means th a , a part icu,ar feature, structure or 
characteristic described in connection with the embedment is included In a, 
■teas, one embodiment of the present Invention. Thus, the appearances of the 
Phrase ,n one embodiment" appearing in various places throughout the 
speafication are not necessarily all referring to the same embodiment 

F,gure 1 is a diagram of . policy enforcement point interacting with a 
poiroy dec,s,on poi „ t for dynamic policy actions aecordjng ^ 

he present invention. A policy enforcement point (PEP) 10 may be a dedicated 
dev.ee for providing network functionality that implements a poiicy in a pbnm 
system architecture. For exampie, the PEP may comprise a network router a 
swrtch, o, a firewall. A PEP may be a client in a client/server model such as is 
used in the COPS protocol. A policy decision point (POP, 12 correlates policy 
norma,™ to instruct one or more PEPs in handiing network packers o 
ofterw.se proving network sendees. A POP m ay be a server in the 
ctiemWer mode!. In one embodiment, the POP may be a genera, purpose 
computer system. There may be one or more PDPs and one or more PEPs in 

117°* archtec,ure - Mul,iple PDPs may be ,inked h * 

^ In this protocol, a PEP sends request, update, and delete messages to a 
POP, and me POP returns decision messages back (o the PEP. Hence the 
PEP communicates with the POP to obtain policy decisions or directives for 
network management. The protoco, uses the weil-known transmission controi 
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protocol (TCP) as its transport protocol for reliable exchange of messages 
between the PDP and the PEPs. The protocol relies on the well-known Internet 
Protocol Security (1PSEC) protocol for authentication and security of the 
communications path between the PDP and the PEPs. The protocol is stateful 
in that it allows the PDP to push configuration information to a PEP, and then 
allows the PDP to remove such state from the PEP when it is no longer 
applicable. The PEP is responsible for initiating a persistent TCP connection to 
a PDP. The PEP uses this TCP connection to send requests to and receive 
decisions from the remote PDP. Communication between the PDP and the 
PEP is primarily in the form of stateful request/decision message exchanges, 
although the PDP may occasionally send unsolicited decision messages to the 
PEP to force changes in previously approved request states. 

The policy protocol is designed to communicate self-identifying objects 
which contain the data necessary for identifying request states, establishing the 
context for a request, identifying the type of request, referencing previously 
installed requests, relaying policy decisions, reporting errors, and transferring 
client specific/name space information. 

In Figure 1, PEP 10 sends a COPS request message 14 at run-time to 
PDP 12 in response to some external action within the network, such as a set of 
conditions requiring evaluation by the PDP. The request message may include 
such items as common header information, a client handle, a context object 
containing data, and other parameters. The context object may be used to 
determine the context within which all other message objects are to be 
interpreted. It also may be used to determine the kind of decision to be 
returned from the PDP. The context object specifies the type of event(s) that 
triggered a query. The decision may be a directive or instruction to the PEP 
related to admission control, resource allocation, object forwarding and 
substitution, or configuration. In response to the request message, PDP 12 
returns a decision message 16 to the PEP. Rather than delivering a static 
decision, in one embodiment of the present invention the PDP downloads a 
Java object to the PEP to be executed on the PEP for implementation of the 
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d6Sired ^ n ° J - -y -"tain any program wJnTZTa 
programme language t0 effec , ^ des , ed resu( J» *« 

PEP must include a Java Virtual Machine (JVM) for support™ „ T 

Java object received from the POP ThL T T 

easiV extensible. * « 

in another embodiment a COPS configuration request object (carried in 
a context object wKhin . ^ message ^ fcy ^ ' <*<^ 

y le PEP a ^ 10 WS9er °' «W -sages 

by the PEP are programmable as well. ,„ both ^ tne Java ^ 

programs instiled a, the PEPs are able to interact both w«h each 

and , mp ,emen« actions. Figure 2 is a diagram illustraflng dynamic p!Z 
one according to an embodiment o, the present inven o 7 TZ 
embodiment a PEP ,0 sends a COPS rogues, message , 0 , ^ 
request conflgunAn within a context object A PEP may request to recede 
named conflgurafon informal from fte PDP in , nfe ^ 
«on da te may be in a fom, useful for se«ng system attfbute 2 T a 
PEP. o . may be ,n the form of policy n^es ma, are to be direcfly verged by me 
PEP. ,n response, the PDP sends a Java object to the PEP in a deiL 
message 0. The Java object, when executed a, the PEP, conjr II 
, -d,«,onsforsubsequen.po„cyeva,u a tion. In one embodiment, these al 
may b. . performed a, netwo* Malice. In a ft ema,e embodiment 
av. 0 ,00. sen, ,o the PEP may perfom, any desired processing and no, be 
limited to configuration functions. 

the pl*"^ "* 0 *** j3Va aPp,iCate and executed in 

? T ions in response ,o — °' — «— * 

pX ^ ? 7 pda,e ,he state at °* er ~ <* *■ — 

PEP ). .Th,s feature allows for policies tha, bom detect and manipulate 
'stnbuted ~ **• **> state infonnation. Figure 3 is a ZgrTm 
*s,rat,ng dynamic poiicy condfcons ,a k ing into account n***.^ 
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information according to an embodiment of the present invention. A PEP 10 
sends a COPS request message 22 at initialization time to PDP 12 requesting 
configuration within a context object. In response, the PDP sends a Java object 
to the PEP in a decision message 24. This first Java object configures 
conditions for policy evaluation by the PEP. At some later point in time, an 
event occurs at PEP 10 triggering run-time evaluation of policy conditions. The 
PEP then sends another request message to the PDP. In response, the PDP 
sends another Java object to the PEP. This second Java object then executes 
on this PEP. The second Java object is able to examine and manipulate 
network state information at another PEP 26 or other node in the network as 
part of evaluating policy conditions. In alternate embodiments, the first and 
second Java objects may be sent to the PEP together at initialization time, or 
may be the same object 

In order to allow PBNM functionality to better support rapidly changing 
network capabilities, embodiments of the present invention use delivery of Java 
programs from a PDP to a PEP to allow dynamic extension of both the actions 
taken in execution of policies, as well as the conditions used to evaluate 
whether an action should be taken or not. This allows PEPs to be more flexible 
both in actions and conditions they support and the classes of problems that 
can be addressed. 

In one example of using embodiments of the present invention, a 
monitoring system may be designed which employs a PBNM system along with 
the extensions defined in the present invention. The monitoring system may 
allow policies to be created which specify the maximum latency that a particular 
data flow will experience between two endpoints in a network. An example of 
the use of such a configuration may be a person who accepts telephone orders 
and enters the orders into an order entry system, where the network latency 
between the person's personal computer (PC) system or order entry terminal 
and the server system that executes the order entry system should be kept low 
in order to ensure prompt customer order, entry. In this case, a Java object may 
be installed on each PEP to monitor the latency of packets from the indicated 
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The programs may be stored on a storage media or device (e.g., hard 
disk drive, floppy disk drive, read only memory (ROM), CD-ROM device, flash 
memory device, digital versatile disk (DVD), or other storage device) readable 
by a general or special purpose programmable processing system, for 
configuring and operating the processing system when the storage media or 
device is read by the processing system to perform the procedures described 
herein. Embodiments of the invention may also be considered to be 
implemented as a machine-readable storage medium, configured for use with a 
processing system, where the storage medium so configured causes the 
processing system to operate in a specific and predefined manner to perform 
the functions described herein. 

An example of one such type of processing system is shown in Figure 4, 
however, other systems may also be used and not all components of the 
system shown are required for the present invention. Sample system 400 may 
be used, for example, to execute the processing for embodiments of the 
extensible policy-based network management system, in accordance with the 
present invention, such as the embodiment described herein. One or more of 
the PDP and PEP may be implemented on a sample system. Sample system 
400 is representative of processing systems based on the PENTIUM®!!, 
PENTIUM® III, and CELERON™ microprocessors available from Intel 
Corporation, although other systems (including personal computers (PCs) 
having other microprocessors, engineering workstations, other set-top boxes, 
switches, routers, and the like) and architectures may also be used. In one 
embodiment, sample system 400 may be executing a version of the 
WINDOWS® operating system available from Microsoft Corporation, although 
other operating systems and graphical user interfaces, for example, may also 
be used. 

Figure 4 is a block diagram of a system 400 of one embodiment of the 
present invention. The system 400 includes a processor 402 that processes 
data signals. The processor 402 may be a complex instruction set computer 
(CISC) microprocessor, a reduced instruction set computing (RISC) 
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local area network (LAN), a wide area network (WAN), the Internet, or other 
network. In some embodiments, a display device controller 416 may be 
coupled to the first I/O bus 412. The display device controller 416 allows 
coupling of a display device to system 400 and acts as an interface between a 
display device (not shown) and the system. The display device receives data 
signals from processor 402 through display device controller 416 and displays 
information contained in the data signals to a user of system 400. 

A second I/O bus 420 may comprise a single bus or a combination of 
multiple buses. The second I/O bus 420 provides communication links between 
components in system 400. A data storage device 422 may be coupled to the 
second I/O bus 420. The data storage device 422 may comprise a hard disk 
drive, a floppy disk drive, a CD-ROM device, a flash memory device, or other 
mass storage device. Data storage device 422 may comprise one or a plurality 
of the described data storage devices. 

A keyboard interface 424 may be coupled to the second I/O bus 420. 
Keyboard interface 424 may comprise a keyboard controller or other keyboard 
interface device. Keyboard interface 424 may comprise a dedicated device or 
may reside in another device such as a bus controller or other controller device. 
Keyboard interface 424 allows coupling of a keyboard to system 400 and 
transmits data signals from a keyboard to system 400. A user input interface 
425 may be coupled to the second I/O bus 420. The user input interface may 
be coupled to a user input device, such as a remote control, mouse, joystick, or 
trackball, for example, to provide input data to the computer system. A bus 
bridge 428 couples first I/O bridge 412 to second I/O bridge 420. The bus 
bridge operates to buffer and bridge data signals between the first I/O bus 412 
and the second I/O bus 420. 

Embodiments of the present invention are related to the use of the 
system 400 as a PDP or PEP. According to one embodiment, such processing 
may be performed by the system 400 in response to processor 402 executing 
sequences of instructions in memory 404. Such instructions may be read into 
memory 404 from another computer-readable medium, such as data storage 
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embodrments, «. d escrip«on » no. intended to be constaed in a Mting 
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embody of the invenHon, which are apparent to persons s«ed in the art 
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CLAIMS 

What is claimed is: 

1 . A method of extending network capabilities for a network with a 
policy-based network management (PBNM) architecture comprising: 
sending a first message from a policy enforcement point (PEP) to a 

policy decision point (PDP) in response to an external action; and 

sending a Java object in a second message from the PDP to the PEP 
in response to receiving the first message. 

2. The method of claim 1 , further comprising executing the Java 
object on the PEP to implement a policy. 

3. The method of claim 2, wherein the Java object interacts with 
another PEP in the network in evaluating conditions and implementing 
actions. 

4. The method of claim 1 , wherein the PBNM architecture operates 
according to a Common Open Policy Service (COPS) protocol, the 
first message comprises a request message, and the second 
message comprises a decision message. 

5. The method of claim 1 , wherein the Java object comprises an 
executable program. 

6. A method of extending network capabilities for a network with a 
policy-based network management (PBNM) architecture 
comprising: 

sending a first message from a policy enforcement point (PEP) to a 
policy decision point (PDP) requesting configuration of conditions; 

14 
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9 10 a Con ™on Open Policy Service (COpc* „ ♦ . 
message comprises . deci5jon *— - 

8. The method of clai m 6, wherein sending the first m . 
*e second message, and execuhng 

at n etW)rk initialization tone. 9 ^ JaVa ° b,ect are ^"ned 

9. A ™^ trf ^nd i ng„e^ capabi|itiesfora . 
^ne^management^^^l-- 

sendinga^,: ^r*"^ 
ppp. °jeci in a second message from the pdp t« 

" reSponse to reiving the first message; ** 

executing the first Java object nr. DCO < 

e^Zr ^ meS5a9e ^ ^ «° ^ P ° P .c an 

. ending a second Java object in a fourth message from the POP ,„ «, 
PEP in response to receiving the fourth message* and 
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10. The method of claim 9, wherein the PBNM architecture operates 
according to a Common Open Policy Service (COPS) protocol, the 
first and third messages comprise request messages, and the 
second and fourth messages comprise decision messages. 

11. The method of claim 9, wherein sending the first message, sending 
the second message, and executing the first Java object are 
performed at network initialization time. 

12. A policy-based network management (PBNM) system for a network 
comprising: 

at least one policy enforcement point (PEP) to send a first message in 
response to an external action; and 

at least one policy decision point (PDP), coupled to the at least one 
PEP, to send a Java object in a second message to the at least one PEP in 
response to receiving the first message. 

13. The system of claim 13, wherein the at least one PEP executes 
the Java object to implement a policy. 

14. The system of claim 13, wherein the Java object executing on the 
at least one PEP interacts with another PEP in the network in evaluating 
conditions and implementing actions. 

15. The system of claim 13, wherein the system operates according 
to a Common Open Policy Service (COPS) protocol, the first message 
comprises a request message, and the second message comprises a 
decision message. 

16. The system of claim 13, wherein the first message comprises a 
request for configuration of conditions, and th at least one PEP 
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sending a first message from a policy enforcement point (PEP) to a 
policy decision point (PDP) in response to an external action; and 

sending a Java object in a second message from th PDP to the PEP 
in response to receiving the first message. 

22. An article comprising: a machine readable medium having a 
plurality of machine readable instructions, wherein when the instructions are 
executed by at least one processor, the instructions implement a policy-based 
network management (PBNM) system by 

sending a first message from a policy enforcement point (PEP) to a 
policy decision point (PDP) requesting configuration of conditions; 

sending a Java object in a second message from the PDP to the PEP 
in response to receiving the first message; and 

configuring conditions controlling the sending of messages from the 
PEP to the PDP. 

23. An article comprising: a machine readable medium having a 
plurality of machine readable instructions, wherein when the instructions are 
executed by at least one processor, the instructions implement a policy-based 
network management (PBNM) system for a network by 

sending a first message from a policy enforcement point (PEP) to a 
policy decision point (PDP) requesting configuration of conditions; 

sending at least first and second Java objects from the PDP to the PEP 
in response to receiving the first message; 

configuring conditions controlling the sending of messages from the 
PEP to the PDP; and 

in response to an event occurring at the PEP, evaluating a policy 
condition and examining a state of another PEP in the network. 
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